High Availability

This article introduces the configuration and recommendations related to Zadig's high availability.

# High Availability Guarantee

Includes high availability for K8s infrastructure, Zadig system components, and databases.

# High Availability of K8s Resources

The high availability of basic resources is guaranteed by the provider of Kubernetes cluster (public cloud/self-built cloud).

# High Availability of Applications

The following recommendations are provided to ensure the high availability of applications:

Use K8s native deployments to ensure that services can be quickly restarted if they exit abnormally
Through the built-in metric interface, combined with Prometheus and pre-configured Grafana dashboards, monitor the performance metrics (CPU/Memory utilization) of Zadig components in real-time
According to the business scale, configure appropriate resource specifications for each component, refer to the microservice.{service}.resources configuration item in the values.yaml file of Zadig Chart
Combine Prometheus Alertmanager to configure monitoring and alerts for core components, recommended alert rules:
- aslan, cron, hub-server components: trigger an alarm when the CPU or memory usage reaches 70% of the resource configuration upper limit and lasts for more than 2 minutes
- dind component: An alarm is triggered when the CPU or memory usage reaches 80% of the resource configuration limit and lasts for more than 2 minutes
Backup the current installation parameters and Chart:
- Get the current installation parameters through helm get values <Zadig Release Name> -n <Zadig Namespace> > Zadig.yaml
- Backup the current Chart through helm pull koderover-chart/zadig --version=<version>
Configure multiple replicas for the application and adjust the number of component replicas based on business usage and resource consumption:
aslan: You need to prepare a ReadWriteMany type StorageClass or PVC. Specify in Helm Values:
```
microservice.aslan.replicas: <replicas>
microservice.aslan.storageClass: <storageClassName>

or

microservice.aslan.replicas: <replicas>
microservice.aslan.existingClaim: <pvcName>
```
1
2
3
4
5
6
7
zadig-portal: Specify in Helm Values:
```
frontend.replicas: <replicas>
```
1
user: Specify in Helm Values:
```
microservice.user.replicas: <replicas>
```
1
hubserver: Specify in Helm Values:
```
microservice.hubServer.replicas: <replicas>
```
1
dind: Reference Dind Configuration

# High Data Availability

It is recommended to use highly available MongoDB and MySQL storage media during installation and to back up Zadig system data regularly:

Using highly available databases, taking Alibaba Cloud as an example:
- MySQL is recommended to use RDS MySQL High Availability Edition
- MongoDB should use dedicated instances
Use highly available artifact repositories:
- Use highly available image repositories/Helm repositories provided by cloud vendors
- If using a K8s Helm Chart project, it is recommended to integrate highly available object storage and set it as the default, data backup is recommended: once a day
Regularly back up database data:
- If using a public cloud, you need to manually set up the automatic backup policy for the public cloud's MySQL/MongoDB instances
- Backup strategy recommendation: once a day
- MinIO backup strategy: once a day

# FAQs

Reference: Deployment and Maintenance FAQs

← Backup & RestoreArchitecture→